This looks ok to me but it needs a docstring.

Right. Done.

This can go in 0.13.1, need to test for the exception being raised and add a release note, i'll merge.

The exception code was already there, so I assume it works. Where should I add the release note?

doc/source/[v0.13.1.txt,whatsnew.rst].

I'm confused. Isn't this opposed to the logic of the SettingWithCopy errors?

Why isn't the resolution to make the BlockManager copy the array in place before doing the sort? (views share BlockManagers right?)

Or maybe I'm not clear why this is a public method vs method on the SingleBlockManager.

I'm confused too. What does providing an is_view method on series have to do with any of that?

Okay, let me take a step back: what's the rationale for making this a public method?

iIIRC the view stuff needs to be taken out
is_copy needs to be set (if needed, eg the series was actually sorted)

sort/order/sort_index have an open issue to have their API fixed iirc

Ok, I haven't kept up with those changes and considered this a harmless addition.
If I was too hasty, we can revert.

Can we revert it temporarily and revisit after we push 0.13.1?

Sure, but before that, can you explain the issue in a way I can grok?
I feel like I stepped in something I don't understand, if you'll excuse the
mixed metaphor.

Issue that arose often was that people used chained assignment and accidentally set values on copies (accomplishing nothing). @jreback added a SettingWithCopy warning that checks for setting values on non-explicit copies (ie not from copy() or methods that return a new object).

So now the general instruction is that you want to work with views not (accidental) copies. This method suggests the opposite mindset.

It also exposes the user to a numpy implementation detail that (I'm speculating) doesn't make sense for pandas.

you almost always get a new pandas object from operations (except when they r inplace)
prob is various chained assignments can't know this because of the way python evaluates statelessly

so an assignment could be working on a non explicit copy

setting is_copy on cross sectional ops like take (which sort effectively does)
makes this clear to the following operations u do with the object

normally will not matter/trigger except when a copy is for sure created (eg u know it's not a view)
and the. u try to set it

(the false positive is you are actually NOT doing a chained assignment)

pandas differs from numpy here because we can make a guarantee that an op returns a copy
just trying to make it explicit where it can be so that subsequent operations can look to that guarantee and provide a warning (if needed)

I had a suspicion that part of the issue was an argument that this reifies the connection
to numpy arrays, that ship has long sailed IMO. In fact we usually present it as a feature.

The chained assignment issue and fix I'm aware of (as well as some recoil by users on the warnings,
@jseabold too in fact). how is_view suggests you use copies instead of a view I'm not sure, nor how
you can use a view instead of a copy ("the general instruction") if what you want to do is mutate the array.

I'm probably just missing 600 comments or so in other issues, too late for that.
I'll revert and open an issue for 0.14 referencing this. seems I no longer have
the overall view (bad pun) needed to make an informed decision, I'll steer clear
in the future.